Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-crocker-pci-00.txt

Text File | 1993-06-16 | 23KB | 620 lines

Internet Draft                PCI             (Expiration:  3/94)




D. Crocker
Network Working Group                                  D. Crocker
Internet Draft <STIF>                      Silicon Graphics, Inc.
Expiration <3/94>                                     9 June 1993






         Encoding for Personal Contact Information (PCI)






STATUS OF THIS MEMO

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups.  (Note that other groups may also
distribute working documents as Internet Drafts).

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time.  It is not appropriate is use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."

Please check the Internet Draft abstract listing contained in the
IETF Shadow Directories (cd internet-drafts) to learn the current
status of this or any other Internet Draft.



SUMMARY

Extensive use of Internet electronic mail demonstrates a need to
be able to communicate various descriptive information about
participants.  The information ranges from telephone and postal
addressing, to an indication of the media supported by their
electronic mail and information processing environment.  This
specification provides a basis for encoding such  "PCI" business
card information by using the STIF [CROC93] syntax.

A MIME Content sub-type is defined for carriage of PCI
information.



TABLE OF CONTENTS
1.        INTRODUCTION
2.        MIME Content-Type for Carriage of PCI Information
3.        PCI FRAMEWORK
     3.1  Basic Syntax
4.        ADDRESSING DETAIL
     4.1. Electronic Mail Detail
     4.2. Postal Mail Detail
     4.3. Facsimile Mail Detail
     4.4. Telex Mail Detail
5.        DESCRIPTION DETAIL
6.        CAPABILITIES DETAIL
7.        REFERENCES
8.        SECURITY CONSIDERATIONS
9.        ACKNOWLEDGEMENTS
10.       CONTACT
A.  Example of Personal Contact Information



1.  INTRODUCTION

Extensive use of Internet electronic mail demonstrates a need to
be able to communicate various descriptive information about
participants.  The information ranges from telephone and postal
addressing, to an indication of the media supported by their
electronic mail and information processing environment.  This
specification provides a basis for encoding such  "PCI" business
cardinformation by using the STIF [CROC93] syntax.

EMail often contains a set of information headers, or free-format
text, at the end of the message intended to convey various
information about the originator of the message.  There is no
formal specification which permits automated exchange of such
information so that it can be incorporated into an on-line
information base.  Further, there is no way for a sender to
provides recipients with similar information about each other.

At its simplest, the PCI/STIF/MIME mechanism permits the exchange
of "business card" information in an automated fashion.  Hence,
its benefits should be an on-line equivalent to that derived when
business associates exchange contact information.

This specification provides a detailed structure for encoding the
wide range of contact and description information needed by
communicants.  It includes fine-grained specification for
delivery through various media and specification of the human
communication media support available to a participant.

A MIME Content-type is defined for carriage of PCI information.



2.  MIME Content-Type for Carriage of PCI Information

PCI information is encoded with the STIF syntax, and can be
carried in MIME [BORE92] messages:

MIME type name:              TEXT

MIME subtype name:    PCI

Required parameters:  none

Optional parameters:  charset = xxx

       This defines the alternate STIF character set.  Legal
       character sets are the same as defined in MIME.

Encoding considerations:

       Alternate character set characters, and some US-ASCII
       characters cannot be sent through some transport services
       directly.  Transports that do not support such data
       should enocode the data appropriately.  Where possible,
       it is recommended that quoted-printable be used, to
       preserve some level of human-readability.

Security considerations:

       See separate section in the documen t.

Published specification:

       This document and its companion, Structured Text
       Interchange Format (STIF), with additional specification
       at the end of this section.

Rationale:

       Provides human- and machine-processable means of encoding
       common personal contact information.  This will permit
       automated processing, such as for maintaining personal
       files of contact information.

Contact-info:

       See Contact section, below.

Detail specific to MIME-based usage:

       Within a MIME body-part, PCI data are to be encoded as a
       series of headers, in the style of RFC 822.  Each header
       has a name, which serves as the reference key to a set of
       data.  Usually, the key should be a version of the
       person's name which has been stripped of seconday text,
       such as titles and salutations:

pci-entry         =  *( pci-key ":" pci-info )

pci-key           =  field-name
                            ; specifies the string to be used
                               for filing the entry, usually
                               name minus titles, etc. >

field-name        =  < As defined in RFC822>



3.  PCI FRAMEWORK

PCI permits structured, extensible specification of information
about a person or some other "reachable" resource.  Use of the
STIF syntax permits machine processing of the PCI content.  PCI
entries are specified one per STIF Header, rather than in the
compressed,  list-oriented format of RFC822 which allows multiple
addresses per line.

Information is specified by a set of STIF fields which are named
from a single, flat name space.  Extensions to this document are
to be registered with IANA, as described in the MIME
specification [BORE92].  For convenience, this document discusses
the initial set of PCI fields in three different sections.  The
first provides information about various addressing alternatives,
including electronic mail, postal mail, facsimile transmission,
and telex transmission.  The second set of PCI fields cover
descriptive information about a person, such as their personal
name, organizational affiliation, title, and telephone contact
number.  The third set of information specifies the capabilities
of the person's electronic mail service.  This allows the sender
or agent software for the recipient to determine what alternate
routing or gateway translations are to be provided.


3.1    Basic Syntax

pci-part          =  1*( pci-descrip / pci-capable / pci-nest )
                            ; described below

pci-nest          =  nest-name "<" pci-info ">"
                            ; PCI-specific use of STIF nesting
                               capability

nest-name         =  "work" / "home" / x-pci

x-pci             =   "x-" word
                            ; private extension

Note that RFC 822 lists of addresses, within a field, have been
modified to be lists of STIF headers.   PCI entries may contain
two types of information:

1.     Addressing Detail provides basic contact information,
sufficient to allow contact via a variety of transport
mechanisms, such as postal, telex and email.

2.     Description Detail provides information about the
addressee, some of which may be required by some media, but which
may otherwise be of interest.  The addressee's name and the name
of their organization are examples of such information.

3.     Capabilities Detail provides guidance about the
addressee's support of various on-line media and, possibly,
conversions they would prefer when they lack a capability.  For
example, they may have a fax machine but not have on-line
graphics capabilities and they may wish that graphics body-parts
be sent to them via facsimile.  (This specification does not
dictate behavior by electronic mail transport services, so that
use of capabilities information is outside of the scope of this
document.)



4.  ADDRESSING DETAIL


4.1.   Electronic Mail Detail

Specification of electronic mail addresses is similar to the
style used for RFC 822-based encoding, except that reference to
the formal, presentation name of a person is separated into its
own field, since it may be used without any reference to email.
Further, an email address may be characterized as to type.  This
is intended to allow user agents to perform contingent actions,
depending upon the type of email address.  For example, a reply
to a message which includes an email reference to a list or
bboard may cause the user agent to obtain confirmation from the
sender, so that such addresses are not included in replies
automatically and possibly by accident.

email             =  "email" ":" addr-spec
                    [ "/" email-type ]
                            ; standard RFC 822 on-line address,
                               without the human name portion
                               (instead placed in Name field)

email-type        =  "person" / "list" / "list-owner"
                            ; distinguish the type of mail
                               address referent.
                            ; a "list" distributes copies to
                               multiple recipients
                            ; "list-owner" directs the message
                               to the address responsible for
                               administering the named list


4.2.   Postal Mail Detail

The specified fields refer to typical categories of postal
information that are used.  Note that such information is order-
dependent to the Postal Service.  For example, in the United
States, an address which contains both a street address and a
post office box address is delivered to whichever address is
"lower" on the envelope.

Courier-delivered mail specification is treated as a type of
postal delivery, although it may require additional information,
such as the specific courier agency to be used.  Also, some
courier agencies require the specification of the recipient's
telephone number.

Since the service provided by one electronic mail gateway may
differ from that of another, or the authorization to use it may
be restricted, specification of a particular postal gateway is
permitted.

paper            =   [name]
                    [org]
                    paper-set
                    [paper-gateway]

paper-set        =   internal / postal / courier / printer


    << How would you like the printer reference to work?? >>

internal         =   1*2( dept / mailstop )
                            ; sufficient for routing within an
                               organization, but not for routing
                               by  public postal system

mailstop         =   "stop" ":" ephrase
                            ; address _within_ an organization

postal           =   [internal]
                    drop
                    code
                    geo

drop             =   1*2( 1*2(street) / pobox )
                            ; Street or Post Office Box or both
                            ; Note that the last to appear will
                               be used by the postal service

street            =  "street ":" ephrase

pobox             =  "box" ":" ephrase
                            ; postal box

code              =  "code ":" word
                            ; zip code, postal code, or the
                               equivalent postal routing string

geo               =  "geo" ":"
                    city-val "/" region-val "/" country-val

                            ; geographic location

city-val          =  ephrase

region-val        =  ephrase
                            ; state, province, or the equivalent

country-val       =  word
                            ; conforms to the relevant
                               international reference standards

courier           =  postal
                            ; courier-delivered paper mail uses
                               the same base of information as
                               postal
                    [carrier-name]
                    [account]
                    [deliver-by]
                    [phone]
                            ; phone number of recipient usually
                               is required

carrier-name      =  "carrier ":" ephrase
                            ; if a specific company's service is
                               required

account           =  "account ":" ephrase
                            ; string which specifies the account
                               to which charges for usage are to
                               be  made.

paper-gateway     =  "paper-gate" ":" addr-spec
                            ; Internet address for gateway
                               system  to the paper-based
                               service
                            ; If deliver=paper and no paper-gate
                               is specified, the underlying
                               email  transport service must
                               already know  of such a gateway


4.3.   Facsimile Mail Detail

Facsimile addresses are easily specified, since they consist only
of a telephone number.  However, transmission of facsimile may
require essential configuration information, such as the degree
of precision to the image to be sent or variations in the cover
page to be used.  As with postal, the specification may indicate
a particular gateway service that is to be used.

fax                = [name]
                    fax-phone
                    [grain]
                    [cover-name]
                    [phone]
                    [postal / internal]
                    [pagecount]
                    [instruct]
                    [subject]
                    [fax-gateway]
                            ; optional info needed for cover
                               page
                            ; originator User Header must supply
                               info for cover page, also

fax-phone          = "fax ":" phone-number *( "/" phone-number )

grain              = "grain" ":" ("regular" / "fine")

cover-name         = "cover ":" ephrase
                            ; name of cover page template, if
                               more than one cover page allowed

pagecount          = "page ":" number
                            ; number of pages, _including cover
                               page_ in the fax

instruct           = "instruct ":" ephrase
                            ; handling instructions for
                               facsimile  operator

fax-gateway        = "fax-gate" ":" addr-spec
                            ; Internet address for gateway
                               system  to the facsimile service
                            ; If deliver=fax and no fax-gate is
                               specified, the underlying email
                               transport service must already
                               know  of such a gateway


4.4.   Telex Mail Detail

telex              = telex-addr
                    [answer]
                    [telex-gateway]

telex-addr         = phrase

answer             = phrase

telex-gateway      = "telex-gate" ":" addr-spec
                            ; Internet address for gateway
                               system  to the Telex service
                            ; If deliver=telex and no telex-gate
                               is specified, the underlying
                               email  transport service must
                               already know  of such a gateway



5.  DESCRIPTION DETAIL

A small set of initial descriptors for an addressee are defined
here.  The set is by no means intended to be definitive.  Rather,
it is intended to be indicative of the range of such information
that may be useful and appropriate to specify.

a-descrip         =  name
                 /  title
                 /  org
                 /  department
                 /  phone
                 /  motto
                 /  note

name              =  "name" ":" ephrase
                            ; personal name of addressee

title             =  "title" ":" ephrase
                            ; their position within affiliated
                               organization

org               =  "org" ":" ephrase
                            ; name of affiliated organization

dept              =  "dept" ":" ephrase
                            ; name of work group, within
                               affiliated organization

phone             =  "phone" ":" #phone-number
                            ; voice contact phone number for
                               addressee

phone-number      =  < international telephone number, conforming
                     to f.103 international telephone number
                     format >
                            ; e.g., [phone]

motto             =  "motto" ":" ephrase
                            ; descriptive text, associated with
                               addressee, work group, or
                               organization

note              =  "note" ":" ephrase



6.  CAPABILITIES DETAIL

A sender may choose a delivery address or medium based upon
knowing the capabilities of the recipient.  Similarly, an
electronic mail gateway may choose particular behaviors, such as
encoding formats, based upon such knowledge.  Such information
may be accessible through dynamic query of a directory service.
However, this may not be possible.  An alternative is to allow
the addressee's descriptive information to contain specification
of the range of media support available to that addressee.  For
simplicity, this specification simply provides for listing the
range of MIME content types and sub-types that the addressee's
system can support.

Since stif supports aggregation of references within nested
subsets,  <a-capable> specifications may be used for _each_  of
the nested sets of addressing information.  A user's different
mailboxes may have different capabilities.

a-capable         =  "support" ":" 1#support
                            ; set of MIME content types/sub-
                               types that are supported by this
                               addressee's email system

support           =  type "/" subtype

type              =  < MIME content-type value >

subtype           =  < MIME content sub-type, as appropriate to
                     the indicated type >



7.  REFERENCES

[BORE92]    Borenstein, N. & Freed, N., "MIME (Multipurpose
            Internet Mail Extensions):  Mechanisms for
            specifying and describing the format of Internet
            Message Bodies.  March, 1992, Network Information
            Center, RFC 1341.

[CROC82]    Crocker, D.,  Standard for the format of ARPA
            Internet text messages.  August, 1982, Network
            Information Center, RFC 822.

[CROC93]    Crocker, D.,  Structured Text Interchange Format
            (STIF). Draft, May 1993.



8.  SECURITY CONSIDERATIONS

This specification covers data encoded within a portion of an
email message.  It contains addressing and source-identification
information which is not specially authenticated.  No special
provision is made for confidentially of the data.  No other
security-related concerns apply.



9.  ACKNOWLEDGEMENTS

STIF developed out of a series of conversations, but was
initially focused exclusively for use as enhanced electronic mail
headers.  Steve Crocker suggested separating the information for
use as a personal contact, or PCI, information base.  Details for
facsimile specification were provided by Alan Katz and Jim
Knowles.  Additional review and comments were provided by
Nathaniel Borenstein, Steve Crocker, Ned Freed, Keith Moore,
Marshall Rose and Erik M. van der Poel



10. CONTACT

name:     David H. Crocker;
work      <email:                               [e-mail];
          org:   Silicon Graphics, Inc.;
          street:                        2011 N. Shoreline Blvd.;
          box:   7311;
          geo:   Mountain View / CA / US;       code: 94039-7311;
          phone: [phone];           fax: [phone]>



A.  Example of Personal Contact Information

It is common for Internet mail to contain extensive information
about its sender.  For example:

From:    "Ole J. Jacobsen" <[e-mail]>
Or:    [phone] (Home) or [phone] (Cellular)
Direct:   [phone] (Office) [phone] (Pager)
Fax:   [phone] (Interop) [phone] (Home)
X-Comment: Ignore error messages for "[e-mail]"
       Ole J Jacobsen, Editor & Publisher ConneXions--The
       Interoperability Report
       Interop Company, 480 San Antonio Road, Suite 100
       Mountain View, CA 94040,
Phone: [phone]  FAX: [phone]
Email: [e-mail]



When encoded as a PCI header, this becomes:

Ole J Jacobsen:
  name:   Ole J. Jacobsen
  email:  [e-mail];
  work   <title: Editor & Publisher;
          org:   Interop Company;
          dept:  Connexions -- The Interoperability Report;
          street:                 480 San Antonio Rd., Suite 100;
          geo:   Mountain View / CA / US;            code: 94040;
          phone: [phone];           fax: [phone]>
  home    <phone:                                [phone];  fax: [phone]
2008>
  mobile  <phone:                          [phone]; pager  <phone: +1 415
998 4427> >
  note:   Ignore error messages for "[e-mail]"

Note that the entire entry is tagged with a canonical form of the
person's name.  This tag is different from the formal
presentation string for that person's name.  That is, name is
different from the header-name for the header containing the name
field.  Leading and trailing information, such as "Dr." or
"Ph.D." and "Jr." should be removed from the  header-name,  to
faciliate use of this string as a database storage and search
key.